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Detached Domain Name System (DNS) Information 
Status of this Memo 
This memo defines an Experimental Protocol for the Internet 
community. It does not specify an Internet standard of any kind. 
Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 
Copyright Notice 
Copyright (C) The Internet Society (1999). All Rights Reserved. 
Abstract 
A standard format is defined for representing detached DNS 
information. This is anticipated to be of use for storing 
information retrieved from the Domain Name System (DNS), including 
security information, in archival contexts or contexts not connected 


to the Internet. 
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1. Introduction 


The Domain Name System (DNS) is a replicated hierarchical distributed 
database system [RFC 1034, 1035] that can provide highly available 


service. It provides the operational basis for Internet host name to 
address translation, automatic SMTP mail routing, and other basic 
Internet functions. The DNS has been extended as described in [RFC 


2535] to permit the general storage of public cryptographic keys in 
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the DNS and to enable the authentication of information retrieved 
from the DNS though digital signatures. 


The DNS was not originally designed for storage of information 
outside of the active zones and authoritative master files that are 


part of the connected DNS. However there may be cases where this is 
useful, particularly in connection with archived security 
information. 


2. General Format 


The formats used for detached Domain Name System (DNS) information 
are similar to those used for connected DNS information. The primary 
difference is that elements of the connected DNS system (unless they 
are an authoritative server for the zone containing the information) 
are required to count down the Time To Live (TTL) associated with 
each DNS Resource Record (RR) and discard them (possibly fetching a 
fresh copy) when the TTL reaches zero. In contrast to this, detached 
information may be stored in a off-line file, where it can not be 
updated, and perhaps used to authenticate historic data or it might 
be received via non-DNS protocols long after it was retrieved from 
the DNS. Therefore, it is not practical to count down detached DNS 
information TTL and it may be necessary to keep the data beyond the 
point where the TTL (which is defined as an unsigned field) would 
underflow. To preserve information as to the freshness of this 
detached data, it is accompanied by its retrieval time. 


Whatever retrieves the information from the DNS must associate this 
retrieval time with it. The retrieval time remains fixed thereafter. 
When the current time minus the retrieval time exceeds the TTL for 
any particular detached RR, it is no longer a valid copy within the 
normal connected DNS scheme. This may make it invalid in context for 
some detached purposes as well. If the RR is a SIG (signature) RR it 
also has an expiration time. Regardless of the TTL, it and any RRs 
it signs can not be considered authenticated after the signature 
expiration time. 
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2.1 Binary Format 


The standard binary format for detached DNS information is as 
follows: 
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Retrieval time - the time that the immediately following information 


was obtained from the connected DNS system. It is an unsigned 
number of seconds since the start of 1 January 1970, GMT, 
ignoring leap seconds, in network (big-endian) order. Note that 
this time can not be before the initial proposal of this 
standard. Therefore, the initial byte of an actual retrieval 
time, considered as a 32 bit unsigned quantity, would always be 
larger than 20 hex. The end of detached DNS information is 
indicated by a "retrieval time" field initial byte equal to 0x20. 
Use of a "retrieval time" field with a leading unsigned byte of 
zero indicates a 64 bit (actually 8 leading zero bits plus a 56 


bit quantity). This 64 bit format will be required when 
retrieval time is larger than OxFFFFFFFF, which is some time in 
the year 2106. The meaning of retrieval times with an initial 


byte between 0x01 and Ox1F is reserved (see section 5). 
Retrieval times will not generally be 32 bit aligned with respect 
to each other due to the variable length nature of RRs. 


RR count - an unsigned integer number (with bytes in network order) 


of following resource records retrieved at the preceding 
retrieval time. 
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Resource Records - the actual data which is in the same format as if 
it were being transmitted in a DNS response. In particular, name 
compression via pointers is permitted with the origin at the 
beginning of the particular detached information data section, 
just after the RR count. 


2.2. Text Format 


The standard text format for detached DNS information is as 
prescribed for zone master files [RFC 1035] except that the SINCLUDE 
control entry is prohibited and the new $DATE entry is required 
(unless the information set is empty). SDATE is followed by the date 
and time that the following information was obtained from the DNS 
system as described for retrieval time in section 2.1 above. It is 
in the text format YYYYMMDDHHMMSS where YYYY is the year (which may 
be more than four digits to cover years after 9999), the first MM is 
the month number (01-12), DD is the day of the month (01-31), HH is 
the hour in 24 hours notation (00-23), the second MM is the minute 
(00-59), and SS is the second (00-59). Thus a $DATE must appear 
before the first RR and at every change in retrieval time through the 
detached information. 


3. Usage Example 


A document might be authenticated by a key retrieved from the DNS in 
a KEY resource record (RR). To later prove the authenticity of this 
document, it would be desirable to preserve the KEY RR for that 
public key, the SIG RR signing that KEY RR, the KEY RR for the key 
used to authenticate that SIG, and so on through SIG and KEY RRs 
until a well known trusted key is reached, perhaps the key for the 
DNS root or some third party authentication service. (In some cases 
these KEY RRs will actually be sets of KEY RRs with the same owner 
and class because SIGs actually sign such record sets.) 


This information could be preserved as a set of detached DNS 
information blocks. 


4. IANA Considerations 


Allocation of meanings to retrieval time fields with a initial byte 
of between 0x01 and 0x1F requires an IETF consensus. 


5. Security Considerations 


The entirety of this document concerns a means to represent detached 
DNS information. Such detached resource records may be security 
relevant and/or secured information as described in [RFC 2535]. The 
detached format provides no overall security for sets of detached 


Eastlake Experimental [Page 4] 


RFC 2540 Detached DNS Information March 1999 


information or for the association between retrieval time and 
information. This can be provided by wrapping the detached 
information format with some other form of signature. However, if 
the detached information is accompanied by SIG RRs, its validity 
period is indicated in those SIG RRs so the retrieval time might be 
of secondary importance. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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